home *** CD-ROM | disk | FTP | other *** search
- Path: chronicle.mti.sgi.com!slsv6bt!kanze
- From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
- Newsgroups: comp.std.c++
- Subject: Re: ANSI/ISO Exception Hierarchy
- Date: 09 Jan 1996 15:55:45 GMT
- Organization: SEL
- Approved: austern@mti.sgi.com
- Message-ID: <KANZE.96Jan9165545@slsvewt.lts.sel.alcatel.de>
- References: <4cgog4$jsq@netlab.cs.rpi.edu> <4cipio$pcj@netlab.cs.rpi.edu> <4crabd$91f@netlab.cs.rpi.edu> <4cteo4$32o@netlab.cs.rpi.edu>
- NNTP-Posting-Host: isolde.mti.sgi.com
- In-Reply-To: Etay_Bogner@mail.stil.scitex.com's message of 9 Jan 1996 10:06:59 -0000
-
-
-
- In article <4cteo4$32o@netlab.cs.rpi.edu>
- Etay_Bogner@mail.stil.scitex.com (Etay Bogner) writes:
-
- |> >> |> The design of the exception classes has changed since Plauger's book was
- |> >> |> written, and class "exception" no longer has a member function "raise".
- |> >> |> The exception classes now have only
- |> >> |> default constructor
- |> >> |> copy constructor
- |> >> |> assignment operator
- |> >> |> virtual destructor
- |> >> |> virtual function "const char* what() const;"
- |> >>
- |> >> |> The "what" function returns an implementation-defined null-terminated
- |> >> |> character string.
-
- |> I would suggest that it will return a :
-
- |> typeid(*this).name()
-
- |> as the standard default behavior. This way we don't add another global
- |> string to the executable's data area, and we re-use the already existing
- |> string ( which represents the name of the exception ).
-
- I don't think so. I would expect that the actual string will depend
- upon the environment. My interpretation of what is desirable is an
- outputtable string, which could potentially be part of an error
- message; the class name would hardly qualify.
-
- In my own implementation, the string does depend on the environment
- (environment variables LC_ALL, LC_MESSAGE and LANG). I would expect
- that this is the standard situation.
-
- |> >> Does this include the constructors? I don't see where this is stated in
- |> >> the draft, and as most of the constructors (except bad_alloc and
- |> >> bad_exception) take a reference to a string, I would expect them to
- |> >> invoke the copy constructor for string, which I presume *can* throw
- |> >> bad_alloc.
-
- |> I believe that the string class would best implememnted as a
- |> copy-on-change class, which means that the copy-constructor will not
- |> actually duplicate the string but will increase the reference counter it
- |> uses.
-
- I don't believe that copy on write is allowed in the current draft.
- Each string can have its own unique allocator; how do you implement
- copy on write in such cases? (Hmmm... Maybe this is the answer to my
- question. The string in the exception class uses an allocator that
- gets its memory from a special pre-reserved area.)
-
- Even if copy on write were allowed, I can think of many reasonable
- implementations in which string::data() (or string::c_str()) may throw
- bad_alloc. Maintaining the physical data internally as a contiguous
- buffer makes most of the string manipulation functions relatively
- expensive on long strings. (Since I only use very short strings, this
- doesn't bother me. But it is a point that an implementor may want to
- consider.)
- --
- James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr
- GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
- Conseils, itudes et rialisations en logiciel orienti objet --
- -- A la recherche d'une activiti dans une region francophone
-
-
-